在 Day 12 中，我們建立了一個 Input Router，透過判斷網址是否包含 youtube.com 或結尾是否為 .pdf，成功將不同格式的輸入分流到專屬的萃取通道。這種基於明確字串特徵的判斷，稱為 Rule-based Routing。 然而，當資料進入系統的中後段，我們面臨的不再是「這是什麼格式的檔案」，而是「這篇文章到底在講什麼領域的知識？」。傳統的 IF-ELSE 或 Regex 正規表達式無法理解語意，如果我們想把「資安」類別的文章加上紅色標籤並發送緊急通知，把「後端」類別的文章默默存入 Notion，傳統的路由節點將束手無策。

Semantic Routing 是讓 AI 參與 Workflow 控制權的進階技巧。我們不依賴網址或副檔名，而是利用 LLM 強大的語意理解能力，判斷內容的主題、情緒或意圖，再以此作為分流依據。

• Rule-based Routing：用於流程前端，負責「物理格式」的決策（如分流 PDF、YouTube）。速度快、成本零、100% 確定。
• Semantic Routing：用於流程後端，負責「抽象意義」的決策（如主題分類、緊急程度判斷）。

在我們的知識管家系統中，Semantic Routing 發生在 AI 完成摘要與分類之後，準備執行 Action 之前：

實作與技術分析

Step 1：在 AI 節點確立分類標準
要讓 Semantic Routing 穩定運作，前提是 AI 必須輸出系統能辨識的固定選項。我們在 Day 19 的 workflow 中，已經強制規定分類只能從 [Backend, DevOps, Security, AI, Other] 中挑選。

Step 2：在 n8n 建立 Semantic Switch Node
當 FastAPI 的 /reduce-summary 或 /summarize 回傳 JSON 後，我們要在 n8n 中根據 AI 的判斷進行分流。

• 新增節點：在 HTTP Request 節點後方，新增一個 Switch 節點。綁定變數：將判斷對象（Value 1）設定為 {{ $json.data.category }}。
• 設定規則 ：
  • Rule 1：Equal -> AI (輸出至通道 0)
  • Rule 2：Equal -> Backend (輸出至通道 1)
  • Rule 3：Equal -> Security (輸出至通道 2)
  • Rule 4：Equal -> DevOps (輸出至通道 3)

如此一來，n8n 就能將原本模糊的語意理解，轉化為明確的流程分支。可以讓 Security 通道多接一個 Telegram 通知節點，而其他通道則直接寫入 Notion。